ui/components/filters/logsFilterSidebar.tsx (1)

18-23: Consider renaming the interface to match the component name.

The interface is still named LogsSidebarProps while the component was renamed to LogsFilterSidebar. For consistency, consider renaming to LogsFilterSidebarProps.

♻️ Suggested rename

-interface LogsSidebarProps {
+interface LogsFilterSidebarProps {
 	filters: LogFilters;
 	onFiltersChange: (filters: LogFilters) => void;
 }

-export function LogsFilterSidebar({ filters, onFiltersChange }: LogsSidebarProps) {
+export function LogsFilterSidebar({ filters, onFiltersChange }: LogsFilterSidebarProps) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ui/components/filters/logsFilterSidebar.tsx` around lines 18 - 23, Rename the
props interface to match the component name for consistency: change the
interface named LogsSidebarProps to LogsFilterSidebarProps and update the
component signature/usage where LogsFilterSidebar accepts its props (the
LogsFilterSidebar function parameter and any references to LogsSidebarProps) so
all types and imports refer to LogsFilterSidebarProps.

ui/app/workspace/logs/views/filters.tsx (1)

63-69: Minor observation: local state is set twice on picker interaction.

When the user selects a date, both the inline handler (lines 152-153) and the useEffect (lines 66-69) update startTime/endTime. The useEffect sync from filters is necessary for external updates (e.g., URL restore), but it also runs after the handler's direct state update. This doesn't cause bugs since values are identical, but you could optimize by checking if values differ before updating in the useEffect.

This is a minor optimization and the current implementation works correctly.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ui/app/workspace/logs/views/filters.tsx` around lines 63 - 69, The useEffect
that syncs filters.start_time and filters.end_time always calls
setStartTime/setEndTime even when the local startTime/endTime already match,
causing redundant state updates after the picker's inline handlers; modify the
effect (useEffect) to first compare the current local values (startTime and
endTime) with the parsed filters (new Date(filters.start_time) / new
Date(filters.end_time) or undefined) and only call setStartTime/setEndTime when
they differ, so external updates still propagate but duplicate updates from the
picker are avoided.

ui/app/workspace/dashboard/page.tsx (1)

51-76: Consider extracting shared time period utilities.

TIME_PERIODS and getTimeRangeFromPeriod duplicate similar logic found in ui/app/workspace/logs/views/filters.tsx (LOG_TIME_PERIODS and getRangeForPeriod). Consider extracting these to a shared utility file to reduce duplication.

The current implementation is correct and works well; this is a nice-to-have for maintainability.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ui/app/workspace/dashboard/page.tsx` around lines 51 - 76, TIME_PERIODS and
getTimeRangeFromPeriod duplicate LOG_TIME_PERIODS and getRangeForPeriod from
ui/app/workspace/logs/views/filters.tsx; extract a shared utility module (e.g.,
timePeriodUtils) that exports the canonical constants and function, move the
logic from TIME_PERIODS and getTimeRangeFromPeriod into that module, update both
dashboard.page.tsx (replace TIME_PERIODS/getTimeRangeFromPeriod imports) and
filters.tsx (replace LOG_TIME_PERIODS/getRangeForPeriod imports) to consume the
shared exports, and ensure type signatures and exported names match existing
usages.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes